1. Field of Invention
The present invention relates to processes and systems for managing software development projects and the workflows employed to oversee such projects. More particularly, embodiments of the invention provide processes and systems for relating a workflow status for a software project to the status of software components of the software project.
2. Discussion of Related Art
Developing software applications and products (which includes both initial development and later modifying or adding to the initial development) often requires the coordinated efforts of many developers (e.g., software programmers). This coordinated effort is referred to herein as a “software development effort” or “development effort,” and a body of work (e.g., one or more software products, including software applications) being developed by the effort is referred to as a “software development project,” “software project,” or “project.” A software development effort may comprise one or more software projects. At any given time, as part of a software development effort, multiple developers may be working on different software components of a software development project and/or different versions of these software components (e.g., for different users or situations). Thus, there may be multiple concurrent software development efforts ongoing, at least some of which use or involve the modification of common software components, including different versions of those software components and sometimes multiple versions of components. Frequently, a software development project may involve several, or even dozens or more, of developers and managers, and from a few to even hundreds of software components. Managing one or more software development projects and the concurrent development of these different software components and versions is commonly referred to as configuration management (CM). Computers or computer systems running CM software applications (i.e., programs) assist developers and project managers in the complex task of managing a software development project, including maintaining coherency between different software components and versions. (Hereafter, the term “CM application” may be used to refer to such computers or computer systems, or to a CM program for executing on a computer or computer system.)
A software development effort most often involves adding or improving functionality (i.e., adding features) to a product, and fixing functionality that is not working properly (i.e., fixing defects or “bugs”). Sometimes, a software development effort may involve removing functionality from a product, such as when a customer desires a simplified version of the product. Typically, one or more fixes, feature changes (whether additions, deletions, or a combination), or combinations thereof (each a development “item”) are grouped together as a development unit called an “issue.” At a minimum, an issue is defined by one or more development items, and often includes other information, such as information which may be used to identify a developer working on the issue and/or a software project with which the issue is associated (i.e., a “Target Release” for the issue). The statuses of issues are often tracked as part of a development effort (often with CM software), as an aid to management of the development process; accordingly, tracking information may be added to an issue description. Upon completion, the tracking information (i.e., tracked statuses) may indicate that the issue has been resolved or finished.
A software development effort may comprise any number of issues, with a software project of the software development effort comprising a single issue—in which case the software project may be considered to be the issue—or comprising multiple issues.
Because of the often significant numbers of issues involved in a development effort (which may number in the dozens, hundreds, or thousands), efficient management of development efforts typically relies on use of an issue tracking system to track the progress of the resolution of each issue. Often, tracking systems are implemented using a computer system, for example, as part of a CM application. Such computerized tracking systems may provide a unique identifier (e.g., a serial number) for each issue, and provide data fields that enable a user (e.g., a developer, supervisor, or project team leader) to track the progress of the issue's resolution by indicating status changes and the like (e.g., when the issue is assigned to a particular developer to be completed, when it is sent to the quality assurance (QA) team for testing, or when it is declared tested and complete, etc.), from time to time, and to identify who is responsible for addressing each issue.
As described above, a software development effort, or concurrent efforts, often involves multiple developers working concurrently on different versions of the same and different software components. Some CM applications provide each developer a “workspace” (defined below) in which the developer can add, modify, and delete components of a software project pertinent to the developer's objective (e.g., completion of an issue). Further, a CM application may maintain one or more versions of the project itself (e.g., branches or streams—defined below), and a developer's workspace may be configured to enable the developer to make changes to a particular version of the project. As used herein, a “version” of a software development project (or other software entity) is a set of software components of the project, and for each software component, a version (i.e., instantiation as of a specific date and time) thereof. It should be appreciated that different versions of a software project (or other type of software entity) may have much the same content (e.g., may include much the same set of software component versions) or quite different content. A developer's workspace may be considered a version of the project or as containing a version of the project.
It is often desirable to propagate modifications made in a developer's workspace (e.g., an addition, change or deletion of one or more software objects) to other versions of the project or to other projects, including other workspaces. CM applications often are configurable to provide such propagation. In CM applications having hierarchies of project versions and workspaces, propagation may comprise promotion of software components, in which software components are moved up in a hierarchy from a child version to a parent version, and/or updating of software components, in which software components are moved down in a hierarchy from a parent version to a child version.
In addition to providing the propagation of modified software components, some CM applications provide an issue tracking system that enables a user to record that an issue resolution has been propagated to one or more versions of the project or to other projects. For example, the user can make an entry in the tracking system that indicates that a particular issue resolution has been propagated to a particular version of the project. To determine that an issue resolution has been propagated to a version of the project, the user determines the software components and versions associated with the issue resolution, for example, by looking up the issue resolution in the issue tracking system. Then the user determines whether all of the versions of the software components have been propagated to the version of the project, for example, by looking up the list of software components and their associated versions currently in the project.
Related to issue tracking systems for software projects are workflow applications monitoring a workflow for one or more software projects. A workflow for a software project may be used to indicate or define a lifecycle for the software project, and may comprise a series of stages, related to one another by transitions, through which a software project may progress. In many conventional implementations, developers of software projects manage workflows using a workflow application separate from any CM application and issue tracking system implemented by the developers. A workflow application may maintain (or be used to maintain) a record of a workflow implemented for a software development effort or software project, and may maintain records of the status of software projects or portions of software projects (e.g., individual issues) in the workflow. From these records, users (including managers of software development efforts) may be able to determine quickly the overall status of one or more software projects (e.g., the user may determine that a software project is completed if all the issues in the software project are completed). Such information facilitates predicting, among other things, software project timelines (e.g., when a software project will reach the “Closed”—i.e., finished—stage).
Workflow applications and CM applications typically require that developers update the records maintained in both systems as a software project progresses through a lifecycle. For example, if a developer of a software project finishes his work on one or more software components and propagates his changes to the software components to another version of the software project (for example, from the workspace of the developer to the workspace of a tester), the developer is required to update the CM application's records (i.e., the issue tracking system's records) indicating that the changes have been propagated (i.e., indicate that an issue has been propagated) and the workflow application's records indicating the project's changed status in the workflow (e.g., the issue has moved from the “In Development” stage to the “In Test” stage).
As mentioned above, some CM applications configured to support propagation of software projects may be further configured to update the records of the issue tracking system when a software project is propagated, so the developer may not be required to update separately the CM application's records. In conventional implementations, however, the developer is still required to update the workflow application's records. Some developers have attempted to automate this process by implementing third-party software to integrate a CM application and a workflow application. Such third-party software may, for example, be implemented as a script or a trigger, and may monitor a CM application's records (e.g., records for an issue tracking system) for changes to one or more software projects. When a software project's CM records are updated, the third-party software may take a predetermined action based on the update, such as updating the workflow applications' records for the software project.
Such conventional systems are unreliable and prone to error, such as system error and/or human error. Human error is introduced when one relies on developers to maintain consistency of records. The developers may forget to update records of one or both applications (i.e., the CM application and the workflow application), refuse to update records, or incorrectly update records. System error arises when third-party software is used, as this approach often relies on software that has been put together with little understanding of the systems being interrelated. At best, third-party software methods rely on consistent and accurate monitoring of one system (e.g., the CM application) and the belief that the third-party software has predicted all possible changes that may be made to the one system and may therefore adequately propagate all changes to the other system (e.g., the workflow application). Relying on this belief is at best far from ideal and at worst mistaken.
Accordingly, there is need for a system which provides CM management functionality and workflow application functionality and which keeps the two types of data in sync while a software development effort is in progress, without reliance on a human agent to synchronize information and without needing external systems.